Thanks @OceanWolf
@aoloe Do I add this to master and do some git sorcery so that updates from SVN don't overwrite it? (what sorcery would that be?)

A pleasure, tomorrow, I will have a go at installing scribus from here and seeing what I get. I guess just have to install and run cmake (on debian). Then I will update the instructions in BUILDING and update the docs here to reflect that. Do you know if I also need any build dependencies installed as well?

Also I will squash the commits before you merge into master.

With the svn, does an equivilant to .gitignore exist?

@luzpaz i made a try yesterday evening with a README_github.md and chitz was not happy with it and we (he; thanks!) reverted the commit.
for now, i think that we should add the readme to the scribus.io site and not to the repository.
and change the status line at the top of the github/scribus page with a link to that readme file.
at some time, i think that we should do some tests with an ad hoc repository and see how we can manage differences between github and svn.
for now i think that we should avoid that and maybe try to get the changes upstream in svn.

Sure I can address those comments, but what/who does chitz refer to?

chitz is the contributor who has created the script for keeping the github repository in sync with the svn one.
he knows git way better than i do and explained me why (for now) it's not a good idea to have files on github that are not the same as on svn.
we had a discussion on irc yesterday evening and he helped to revert the change i made.

life is complicated :-)

Darn, any chance of copying the reasoning over to here? At least for reference purposes... also I feel curious with what you mean by "for now"...

in short:

• why it does currently not work (correctly)? several people are doing the update by running the script against their local copy of the github / svn repository. if there are changes that are specific to the github repository, the order of the commits will not be the same for each commiter and the problems might arise.
• why for now? we have to test it on "ad hoc" repository and see if there is a workaround that works for us... personally, i'd like to have differences (like the README) without going for a fork... so i might take some time to check this out. but not right now.

Ahh, okay, what do you think about rewriting the readme so that it can apply to both svn and git?

Something along the lines of "people wanting to help develop Scribus should do so through the github repository at https://github.com/scribusproject/ for more information see http://scribus.io/", or does the Scribus Team not want to give us such a blessing just yet ;).

Not really important, just if an easy option like that exists, then we might as well take it.

@aoloe opinion ?

DW, I will scrap this and rewrite the readme, first I want to get the documentation sorted in #25

right now, at least part of the team seems to be rather allergic to github...

personally, i don't like the current README.

the question is: for whom should a README be written? who reads a README file?

my answer (ok, it's probably also my point of view): people who have downloaded (or are ready for downloading) the source code. a big part of them are potential developers. the other big part are testers. we should write a much shorter text that appeals to them and move the what's new file to a CHANGELOG file (that gets updated when important features are implemented).

right now, the main message i get from the README is: "hey, look at us and see how we are cool"... it's an sane approach, but it does not fit "my way" and i'm not sure that it's the most useful message in that file.

proposing a new good README could be an approach for improving the current state.

👍 My sentiments exactly, as you see I did exactly that here, well, I only copied the readme to a what's new, because at first I didn't want to change anything already existing, but in the last few comments here that has changed to "lets make one document that both the team and us feel happy with".

I regularly now come onto the IRC channel, so I could announce it there once I have a first draft of this one readme to rule them all, and at the same time ask for feedback (and help/encourage people to use the github feedback mechanism, i.e. PR Comments (like this one) and Line Comments).